Disclaimer: I may understand this imperfectly.
The role of the AllowedSystemId may differ. In EU-Spirit it is used in InitialInput to tell the RCC to which passive servers the request shall be passed. [In EU-Spirit the OJP services do not interact directly, but only via the RCC].
I understand that there may be an advantage to have the AllowedSystemId information available outside the InitialInput. Maybe you could elaborate a bit more what kind of procedure you have in mind. Do you want to have a chane to get an overview about available systems automatically before the actual request?

@JonaVBB I think that in a distributed context it is sometimes necessary to know which system is the "owner/master" of the element (here place). In theory otherwise they might have the same id. i would add a SystemId everywhere, where this distinction is necessary. may be also in TripInfoRequest. What do you think?

@JonaVBB could you please comment?

To me it seems we're talking about two different ways of using this element (spoiler: I don't see a problem using both in parallel).

The initial idea from EU-Spirit derives from EU-Spirit's algorithm. AllowedSystemId is used by active servers/nodes to tell the RCC (central component) which passive servers/nodes shall be used to calculate the journey. So, AllowedSystemId is then a list of IDs which are allowed/defined to be asked. Passive systems which are not mentioned in the AllowedSystemId will not be asked by the RCC.
Second aspect (and new for me, but still ok): if I understand it correctly, you would put an AllowedSystemId in each part of responses to "assign" certain elements to a system they are originating from. Am I right? Yes, this might help.